dgit.raspbian.org Git - git-annex.git/blob

   1 [[!comment format=mdwn
   2  username="joey"
   3  subject="""comment 1"""
   4  date="2021-09-06T18:52:21Z"
   5  content="""
   6 I tried to reproduce this on Linux, and cannot:
   7
   8         joey@darkstar:~/tmp/r>/usr/bin/time git-annex get bigfile
   9         get bigfile (from origin...)
  10         ok
  11         (recording state in git...)
  12         11.66user 2.08system 0:13.76elapsed 99%CPU (0avgtext+0avgdata 99012maxresident)k
  13         206440inputs+2048856outputs (46major+21865minor)pagefaults 0swaps
  14         joey@darkstar:~/tmp/r>git annex drop
  15         drop bigfile ok
  16         (recording state in git...)
  17         joey@darkstar:~/tmp/r>/usr/bin/time git annex sync --no-commit --no-push --no-pull --content-of bigfile
  18         get bigfile (from origin...)
  19         ok
  20         (recording state in git...)
  21         11.43user 1.91system 0:13.43elapsed 99%CPU (0avgtext+0avgdata 97132maxresident)k
  22         60016inputs+2048312outputs (25major+11680minor)pagefaults 0swaps
  23
  24 One reason it may do an extra checksum is if for some reason the inode
  25 cache is stale. Since [[!commit 3b5a3e168d8decd196509ad582ad4b8795d979a6]]
  26 it will check that and checksum before starting to send the content.
  27
  28 In this case, it will display "(checksum...)" before the progress display
  29 has started.
  30
  31 One way I can reproduce that, on Linux, is to touch the annex object file
  32 in the remote git repository before running git-annex. This is the result:
  33
  34         joey@darkstar:~/tmp/r>/usr/bin/time git-annex get bigfile
  35         get bigfile (from origin...) (checksum...)
  36         ok
  37         (recording state in git...)
  38         22.06user 2.22system 0:24.85elapsed 97%CPU (0avgtext+0avgdata 97192maxresident)k
  39         704inputs+2048432outputs (33major+10701minor)pagefaults 0swaps
  40
  41 But that shows that git-annex get also behaves that way, which does not
  42 explain why only git-annex sync would have the problem for you.
  43 (And the two run the same code; sync literally runs code from get.) Also
  44 I don't know why the inode cache would be getting stale on windows.
  45
  46 If it does not display "(checksum...)" before the progress display,
  47 it's certianly not that. And if it does not display "(checksum...)"
  48 at any point at all, that would be good to know, because normally
  49 git-annex does display that when checksumming.
  50 Your transcript seems to show no such output.
  51
  52 At the "2021-08-27 00:15:36.6868986" timestamp in your log, it's just
  53 completed updating the location log, and you identify the pause after that
  54 as where it's checksumming. So that seems to suggest it's already
  55 transferred the content there, and updated the location log, before
  56 checksumming. But it doesn't do anything normally
  57 after updating the location log, and it won't update the location log
  58 before it's satisfied it transferred the right content, so after any
  59 checksumming.
  60
  61 Possibly `git annex sync` is trying to drop the content from some
  62 remote due to its preferred content setting no longer wanting the content
  63 to be there. Do you have preferred content expressions configured?
  64 (I'm doubtful about this theaory because I don't think it ever hashes the
  65 content during a drop, but one difference between `get` and `sync`
  66 is that sync drops..)
  67
  68 Only other thing I can think that it could be is perhaps git is running
  69 the smudge/clean filter on the content, after the transfer, and git-annex
  70 hashes it again when run that way. Hard for me to tell from the filespray
  71 log if that might be the case. Setting `GIT_TRACE=1` would show if this
  72 happens.
  73 """]]